IP Multimedia (IPMM) services provide a combination of voice, video, messaging, data, etc, within the same session. As the number of basic applications and the media which it is possible to combine increases, the number of services offered to the end users will grow, and the potential for enriching inter-personal communication experience will be improved. This leads to a new generation of personalised, rich multimedia communication services, including so-called “combinational IP Multimedia” services.
IMS is the technology defined by the Third Generation Partnership Project (3GPP) to provide IP Multimedia services over mobile communication networks. IMS provides features to enhance the end-user person-to-person communication experience through the integration and interaction of services. IMS allows enhanced person-to-person (client-to-client) as well as person-to-content (client-to-server) communications over an IP-based network. The IMS makes use of the Session Initiation Protocol (SIP) to set up and control calls or sessions between user terminals (or user terminals and application servers). The Session Description Protocol (SDP) carried by SIP signalling is used to describe and negotiate the media components of the session. Whilst SIP was created as a user-to-user protocol, IMS allows operators and service providers to control user access to services and to charge users accordingly. Other protocols are used for media transmission and control, such as Real-time Transport Protocol and Real-time Transport Control Protocol (RTP/RTCP).
In an IMS network, Call Session Control Functions (CSCFs) perform processing and routing of signalling. CSCFs handle session establishment, modification and release of IP multimedia sessions using the SIP/SDP protocol suite. 3GPP TS 23.228 describes the logical nodes P-CSCF, I-CSCF, S-CSCF, E-CSCF and BGCF. The S-CSCF conforms to, among others, 3GPP TS 24.229 and performs session control services for User Equipments (UEs). It maintains the session state to support the services, and performs the following functions:
it acts as a registrar according to [RFC3261] at registration;
it notifies subscribers about registration changes;
it provides session control for the registered users' sessions;
it handles SIP requests, and either services these internally or forwards them on to a further node; and
it interacts with IMS Application Servers.
The S-CSCF performs SIP routing according to 3GPP routing procedures.
Within the IMS network, SIP Application Servers (ASs) host and execute services and interface with the S-CSCF via an ISC interface. In the case of a multimedia telephony service, two ASs are worth further consideration here. The Service Centralization and Continuity Application Server (SCC-AS) allows users to access IMS services via various access networks and devices. It also aims to provide for roaming between access networks and for handover of sessions between different types of access networks. The Multi-Media Telephony AS (MMTel AS) facilitates the establishment and control of multimedia sessions including, for example, one or more of voice, video, text, as well as providing a charging point for generating accounting messages (used for online or offline charging).
FIG. 1 illustrates schematically a typical architecture for allowing Multimedia telephony session establishment between two end users, in this example UE-A and UE-B where the former is the calling party and the latter is the called party. [Other network nodes required for this purpose (including the P-CSCF) are omitted for the sake of simplicity.] In FIG. 1, the called party UE-B is shown as possessing two terminal identified as UE-B1 and UE-B2. A stepwise description of the session establishment process with this architecture might be as follows, where it is assumed that the process is triggered by receipt at S-CSCF (A) of an INVITE from UE-A with UE-B as called party:    (1) S-CSCF (A) invokes a first SCC-AS over the ISC reference point.    (2) S-CSCF (A) invokes a first MMTel AS over the ISC reference point.            The first SCC-AS and first MMTel AS are invoked independently of one another; both services are defined in the Initial Filter Criteria (IFC) associated with UE-A.        The first MMTel AS may determine that the destination subscriber for this call, UE-B, is a subscriber of the same domain or the MMTel AS may have made some other analysis on the destination for the call, e.g. belonging to a closed user group. Such analysis, to determine whether the called party, i.e. destination of the call, belongs to the same user group, may be used to give a preferential rate for in-company calls. The first MMTel AS does not, however, always have knowledge of (i) whether the destination subscriber is an IMS subscriber, (ii) the identity of the S-CSCF serving that destination subscriber (if indeed an IMS subscriber) and (iii) the MMTel AS node serving that subscriber (again, if indeed an IMS subscriber).            (3) When S-CSCF (A) has received the INVITE back from the first MMTel AS, it applies number normalization if needed.    (4) Number normalization is followed by an ENUM query by S-CSCF (A), if needed. ENUM allows a destination address to be obtained in a form that can be used in the IMS network. More specifically, this might be a SIP URI.    (5) S-CSCF (A) performs a DNS query, in order to obtain information (NAPTR record, SRV record, A record) for forwarding the session establishment request message to the appropriate I-CSCF.    (6) The I-CSCF performs an HSS query over the Cx reference point, in order to obtain the address of the S-CSCF currently serving the destination party, UE-B.            The HSS may be a “monolithic” HSS or a Data Layered Architecture (DLA) HSS. In the former case, an SLF query by the I-CSCF may be needed, prior to the HSS query. In the latter case, the HSS query is in fact a query towards an HSS front-end.            (7) S-CSCF (B) invokes a second MMTel AS over the ISC reference point.    (8) S-CSCF (B) invokes a second SCC-AS over the ISC reference point.    (9) When S-CSCF (B) has received the INVITE back from the second SCC-AS, it builds a target set and forwards the INVITE to the contact addresses contained in the target set.            It is common for contemporary IP Centrex (a network based telephony application providing PBX-like services) and for MMTel AS to establish a call to multiple terminals of the destination party (in this case UE-B1 and UE-B2) by sending multiple INVITES back to the S-CSCF (B), as opposed to performing “forking” at the S-CSCF (B). Each INVITE that is sent back to S-CSCF (B) is targeted towards one of the destination subscriber's IMPUs. The S-CSCF (B) will then forward the INVITE to the contact address associated with that IMPU. This requires that the IMPUs are provisioned, in the HSS, in separate Implicit Registration Sets (IRS).        
FIG. 2 illustrates schematically a modified and optimized deployment scenario according to which MMTel functionality and the SCC-AS are integrated into a single MMTel AS node. A single service invocation over the ISC reference point suffices for invoking SCC-AS and MMTel AS for the call. The MMTel AS takes care that SCC-AS and MMTel are applied in the appropriate sequence, i.e.:                for the originating call case: first SCC-AS, then MMTel; and        for the terminating call case: first MMTel, then SCC-AS.        
FIG. 3 shows how Value Added Services (VAS) may be applied for the typical MMTel call. Whilst the mechanisms for applying VAS for an MMTel call are currently under discussion, it can be noted that a method that is receiving considerable attention is the use of a ‘northbound interface’ from the MMTel AS, e.g. Parlay-X. This interface allows the MMTel AS to enhance the MMTel service logic processing with VAS control.
It will be appreciated that, according to the currently implemented and proposed architectures, a number of steps are required in order to extend the SIP session from the MMTel AS serving the calling party to the MMTel AS serving the called party. Whilst this approach is appropriate when the calling and called parties are served by different MMTel AS nodes, it may be inefficient when the called and calling parties are served by the same MMTel AS node at the point in time when the call is being established, i.e. the MMTel service engine serving the calling party and the MMTel service engine serving the called party reside in the same MMTel AS node.
It is reasonable to assume that the MMTel service will be the main form a multimedia communication for mainstream operators, and that IMS, including MMTel, VoLTE, SR-VCC etc. is poised to take off from 2012 onwards. MMTel optimizations are therefore likely to be of great value in the coming years.